Creation and access of quota trees in a file system

ABSTRACT

A method of identifying metadata referenced by a quota tree. A quota tree metafile is accessed, and this quota tree metafile includes references to locations of inode grouped data structures associated with quota trees. Here, each quota tree is allocated an inode grouped data structure. A reference to a location of an inode grouped data structure that is allocated to the quota tree is identified from the quota tree metafile. The inode grouped data structure is accessed based on the reference, and this inode grouped data structure defines a set of inode identifiers associated with the quota tree. An inode grouped data structure that stores the metadata is then located using the set of inode identifiers as index.

FIELD

The present disclosure relates generally to information storage. In anexemplary embodiment, the disclosure relates to access and creation ofquota trees in a file system.

BACKGROUND

A storage quota is an allocation of storage. A quota tree is a subtreein a volume's file system, and such a quota tree can be used to indexstorage quotas or other metadata. As an example, a quota tree creates asubset of a volume to which a quota can be applied to limit its size.Many conventional file systems maintain a single table from which allmetadata associated with different quota trees are stored. Even though afile system can be subdivided into different quota trees as anindependent partition, the quota trees still share a common table. As aresult, conflict may arise if one particular quota tree needs aparticular inode on a file system, but that particular inode is in useby another quota tree.

For example, a single volume can be used as a backup destination formultiple quota trees residing on different volumes. However, when aquota tree is copied to this single volume, the inode identifierscorresponding to the quota tree may already have been allocated toanother file residing in another quota tree. As a result, an exact copyof the quota tree having identical inode identifiers may not be storedin this different volume. Instead, the quota trees are assigneddifferent inode identifiers when stored in this different volume, andthe file system needs to store information about the correlation of theinode identifiers such that the original inode identifiers can bereconstructed in case the quota tree needs to be restored from thedifferent volume.

In another example, in logical replication, a database that storescorrelation information needs to be updated for each copy of a quotatree. Due to this constraint, cascade copies cannot be made. That is,the destination volume cannot be copied again. For example, a quota treeis stored on a “first” volume while a secondary copy of the quota treeis stored on a “second” volume. A tertiary copy of the quota tree isstored in a “third” volume. Here, the secondary copy is used to make thetertiary copy. In case the secondary copy fails, the tertiary copycannot be used to restore the quota tree because the tertiary copy doesnot have any correlation information on the quota tree stored in thefirst volume. The tertiary copy only has correlation information on thesecondary copy, but this secondary copy is now inaccessible.

SUMMARY

Exemplary embodiments of the present invention provide varioustechniques for creating and accessing quota trees in a file system.Generally, instead of having one single data structure shared by allquota trees across a file system, embodiments of the present inventionprovide an inode grouped data structure for each quota tree. This inodegrouped data structure stores various metadata of data containersassociated with its quota tree. The allocation of a metafile for eachquota tree allows each quota tree to maintain its own index of inodeidentifiers, which are used to locate the metadata. Given that the inodeidentifiers are maintained per quota tree, different quota trees canhave the same inode identifiers. For example, a copy of a quota tree canhave a set of inode identifiers that are identical to the inodeidentifiers of a source quota tree because the inode identifiers arestored in different inode grouped data structures, thereby avoiding anypotential conflicts of inode identifiers.

Accordingly, when a quota tree is restored from a backup copy, such arestoration operation is simplified because the inode identifiers of thebackup copy are identical to the inode identifiers of the source quotatree. The restoration operation is simplified because the inodeidentifiers of the backup copy do not need to be renumbered to match theoriginal inode identifiers of the source quota tree. Furthermore,embodiments of the present invention also eliminate the need to storecorrelation information used in the renumbering. By allowing quota treesto have identical inode identifiers, embodiments of the presentinvention support fan-in and cascade copies of quota trees. In a fan-incopy, quota trees stored in different volumes can be copied to a singlevolume. In a cascade copy, a secondary copy of a primary quota tree isused to create a tertiary copy. Methodologies to create and access quotatrees having their own inode grouped data structures in accordance withexemplary embodiments of the present invention are also described.

BRIEF DESCRIPTION OF DRAWINGS

The present disclosure is illustrated by way of example and notlimitation in the figures of the accompanying drawings, in which likereferences indicate similar elements and in which:

FIG. 1 is a schematic block diagram of a network environment, inaccordance with an exemplary embodiment;

FIG. 2 is a block diagram depicting various modules, in accordance withan exemplary embodiment, included in a storage server;

FIG. 3 is a diagram illustrating the creation and copy of a quota treewithin a volume, in accordance with an exemplary embodiment;

FIG. 4 is a diagram depicting a copy of a quota tree in a differentvolume, in accordance with an exemplary embodiment of the presentinvention;

FIG. 5 is a flow diagram of a general overview of a method, inaccordance with an exemplary embodiment, for creating a quota tree in afile system;

FIG. 6 is a flow diagram of a general overview of a method, inaccordance with an exemplary embodiment, for creating a new quota treeor copying an existing quota tree;

FIG. 7 is a flow diagram of a general overview of a method, inaccordance with an exemplary embodiment of the present invention, foraccessing a quota tree to identify an inode grouped data structure;

FIG. 8 is a flow diagram of a detailed method, in accordance with anexemplary embodiment of the present invention, for accessing a quotatree to identify an inode grouped data structure;

FIG. 9 is a data block diagram of a file system that supports quotatrees, in accordance with an exemplary embodiment of the presentinvention;

FIG. 10 is a diagram of a system depicting a “fan-in” copy of quotatrees, in accordance with an exemplary embodiment of the presentinvention;

FIG. 11 is a diagram of a different system depicting a “cascade” copy ofquota trees, in accordance with an alternative embodiment of the presentinvention; and

FIG. 12 depicts a hardware block diagram of a machine in the exampleform of a computing device within which may be executed a set ofinstructions for causing the machine to perform any one or more of themethodologies discussed herein.

DESCRIPTION OF EXEMPLARY EMBODIMENTS

The description that follows includes illustrative systems, methods,techniques, instruction sequences, and computing machine programproducts that embody the present invention. In the followingdescription, for purposes of explanation, numerous specific details areset forth in order to provide an understanding of various embodiments ofthe inventive subject matter. It will be evident, however, to oneskilled in the art that embodiments of the inventive subject matter maybe practiced without these specific details. In general, well-knowninstruction instances, protocols, structures and techniques have notbeen shown in detail. Furthermore, the term “exemplary” is construedmerely to mean an example of something or an exemplar and notnecessarily a preferred or ideal means of accomplishing a goal.

FIG. 1 is a schematic block diagram of a network environment 100, inaccordance with an exemplary embodiment. As depicted, the networkenvironment 100 includes client computing devices 110, a storage server152, and storage devices 130. The storage server 152 is a computingdevice that provides file-based service or block-based service relatingto the organization of information on storage devices 130, such asnon-volatile memories, tapes, and disks. A file server is an example ofa storage server 152. The storage server 152 may be embodied as astorage system including a storage operating system 155 that implementsone or more file systems 160 to logically organize the information as ahierarchical structure of directories and data containers on the storagedevices 130. Each data container may be implemented as a file orgenerally a set of data structures (e.g., disk blocks) configured tostore information, such as the actual data for the file. A directory, onthe other hand, may be implemented as a specially formatted datacontainer in which information about other data containers anddirectories are stored.

Each client computing device 110 is configured to execute one or moreapplications 112. Moreover, each client computing device 110 mayinteract with the storage server 152 in accordance with a client/servermodel of information delivery. That is, the client computing devices 110may request the services of the storage server 152, and the storageserver 152 may return the results of the requested services byexchanging packets encapsulated in, for example, Common Internet FileSystem (CIFS) protocol or Network File System (NFS) protocol format overnetwork 150.

Storage of information on the storage server 152 can be implemented asone or more storage “volumes” that comprise a cluster of storage devices130, defining an overall logical arrangement of disk space. Each volumeis generally associated with its own file system 160. To facilitateaccess to the storage devices 130, the storage operating system 155implements a file system that logically organizes the information as ahierarchical structure of directories and data containers on the storagedevices 130. Each “on-disk” data container may be implemented as a setof disk blocks configured to store information, such as data, whereasthe directory may be implemented as a specially formatted data containerin which names and links to other data containers and directories arestored. In the illustrative embodiment described herein, the storageoperating system 155 can be, for example, NETAPP Data ONTAP®, which isavailable from NetApp, Inc. located in Sunnyvale, Calif., or UNIXoperating system that implements a file system.

In the illustrative embodiment, the storage operating system 155,portions of which are typically resident in memory and executed by theprocessing elements of the storage server 152, functionally creates andaccesses one or more quota trees. A “quota tree,” as implemented on anexemplary storage system such as described herein, is a subtree in avolume's file system 160. A quota tree creates a subset of a volume towhich a storage quota can be applied to limit its size. A storage quotarefers to an allocation of storage allotted to, for example, a user, agroup, and/or a directory. As an example, a user may be allotted astorage quota of 500 MB of storage space. Quota trees represent anotherlevel of abstraction at which a storage device can be partitioned.Storage devices are organized into aggregates, which provide pools ofstorage. In each aggregate, one or more flexible volumes can be created,and each volume can be divided into one or more quota trees.

Here, the storage operating system 152 sets up an inode grouped datastructure for each quota tree in a file system 160. Each inode groupeddata structure, as explained in more detail below, defines a set ofinode identifiers assigned to a particular quota tree. With each quotatree having its own inode grouped data structure, each quota tree can becopied to or duplicated in a different volume while still maintainingits inode identifiers.

FIG. 2 is a block diagram depicting various modules, in accordance withan exemplary embodiment, included in a storage server 152. Here, thestorage server 152 may be included in a storage environment, such asforming a part of the storage environment 100 depicted in FIG. 1.Referring to FIG. 2, in various embodiments, the storage server 152 maybe used to implement computer programs, logic, applications, methods,processes, or software to create and access quota trees, as described inmore detail below.

The storage server 152 executes a storage operating system 155 thatmanages other processes and/or services executing on the storage server152. In one embodiment, the storage operating system 155, as alsodepicted in FIG. 1, includes a file system 160 that includes a quotatree replication module 202. In general, the quota tree replicationmodule 202 is configured to create and access quota trees using the filesystem 160. Instead of a single data structure shared by all quota treesacross the file system 160, a data structure for each quota tree isallocated in the file system 160. This data structure, which is alsoreferred to as an “inode grouped data structure,” is a metafile thatstores metadata of data containers associated with a single quota tree.Examples of metadata include storage quotas, permissions, useridentifiers, group identifiers, and other metadata. It should be notedthat an inode identifier is used internally within the file system toidentify the inode associated with the data container. An inode numberis an example of an inode identifier. An “inode” is a data structureused to store the metadata of one or more data containers. The inodeincludes a set of pointers to blocks within a file system. For datacontainers, such as files, the inode may directly point to blocksstoring the data of the file. Given that an inode is a data structure,it should be noted that the terms “inode” and “inode data structure” maybe used interchangeably.

An “inode grouped data structure” therefore comprises a set of “inodedata structures,” with each inode data structure storing a set ofmetadata. Each inode data structure can be indexed within the inodegrouped data structure by inode identifiers. In other words, inodeidentifiers are indexes within an inode grouped data structure and eachindex specify one of many inode data structures. Accordingly, each inodegrouped data structure stores a set of inode identifiers and a set ofcorresponding inode data structures. The following Table A is an exampleof an inode grouped data structure as embodied in a table:

TABLE A Inode identifier Inode Data Structure 0 Type Permission StorageQuota User Identifier and Group Identifier 1 Type Permission StorageQuota User Identifier and Group IdentifierIn effect, the inode identifier can be used to index the metadata. Itshould be appreciated that a “data structure” provides context for theorganization of data. Examples of data structures include tables,arrays, linked lists, databases, and other data structures. Modeidentifiers can be used as index within tables, but it should beappreciated that other indexes may also be used within other datastructures.

As explained in more detail below, the allocation of an inode groupeddata structure for each quota tree allows each quota tree to maintainits inode identifiers. As a result, multiple copies of a single quotatree can be created having inode identifiers that are identical to thesingle quota tree, thereby possibly simplifying the restoration of aquota tree from a copy because, for example, the inode identifiers donot need to be reconstructed to match the inode identifiers of thesingle quota tree.

It should be appreciated that in other embodiments, the storage server152 may include fewer or more modules apart from those shown in FIG. 2.For example, in an alternate embodiment, the quota tree replicationmodule 202 can be further divided into multiple modules. The quota treereplication module 202 may be in the form of software that is processedby a processor. In another example, as explained in more detail below,the quota tree replication module 202 may be in the form of firmwarethat is processed by application specific integrated circuits (ASICs),which may be integrated into a circuit board. Alternatively, the quotatree replication module 202 may be in the form of one or more logicblocks included in a programmable logic device (for example, a fieldprogrammable gate array). The described module 202 may be adapted,and/or additional structures may be provided, to provide alternative oradditional functionalities beyond those specifically discussed inreference to FIG. 2. Examples of such alternative or additionalfunctionalities will be discussed in reference to the flow diagramsdiscussed below.

FIG. 3 is a diagram illustrating the creation and copy of a quota treewithin a volume, in accordance with an exemplary embodiment. When a filesystem is created, a quota tree metafile 302 is created. This quota treemetafile 302 stores various information regarding all quota trees in asingle volume (e.g., volume 1). In one embodiment, the quota treemetafile 302 stores information such as quota tree identifiers (“QTREEID”), root directory inode identifiers (“ROOT DIRECTORY”), andreferences to locations of inode grouped data structures (“LOCATION OFNODE GROUPED DATA STRUCTURE”). The quota tree identifier is a value thatuniquely identifies a single quota tree. For example, as depicted inFIG. 3, the quota tree metafile 302 includes a “QTREE ID” column ofthree quota tree identifiers 0, 1, and 2 that uniquely identify quotatree 0, quota tree 1, and quota tree 2, respectively. Given that thequota tree identifiers uniquely identify quota trees, the values storedin the “QTREE ID” column are unique. That is, the quota tree metafile302 is setup such that no two distinct rows of quota tree identifierscan have the same value.

A root directory inode identifier (or “root inode identifier”) is areserved inode identifier that uniquely identifies a root directory. Inthis example, inode identifier 0 is used to identify the root directory.It should also be noted that a “root directory” refers to the first ortop-most directory in a hierarchy. For example, in UNIX systems, theroot directory is denoted by the directory separator character “/.”Though the root directory is conventionally referred to as “/,” theactual directory entry itself has no name because its name is the emptypart before the initial directory separator character “/.” A file systemmay also have multiple root directories. As an example, in the OpenVirtual Memory System operating system, a root directory refers to adirectory in which all the user's data containers are stored. Withmultiple users, the file system includes multiple root directories.

In this example, quota tree identifier 0 refers to a quota tree thatstarts from a root of the file system. Thus, other quota trees resideinside quota tree 0. That is, quota trees start from one of thedirectories in quota tree 0. This directory maps to the root directoryof each quota tree, and only one quota tree can be created under adirectory. A root directory inode identifier in the quota tree metafile302 therefore refers to an inode identifier in the quota tree 0 thatuniquely identifies a particular root directory of other quota trees inthe file system, the root directory of which provides indirection oraccess to these other quota trees. Thus, the values stored in the “ROOTDIRECTORY” column of the quota tree metafile 302 are also unique. Asdepicted in FIG. 3, given that the data included in each row of thequota tree metafile 302 are associated with each other, the quota treemetafile 302 includes a “ROOT DIRECTORY” column of three root directoryinode identifiers 0, 1, and 6 that uniquely identify the root directoryassociated with quota tree 0, the root directory associated with quotatree 1, and the root directory associated with quota tree 2,respectively.

The inode grouped data structure column of the quota tree metafile 302stores references to locations of inode grouped data structures that areassociated with their respective quota tree identifiers and rootdirectory inode identifiers. As previously discussed, each inode groupeddata structure stores the metadata of data containers residing in thecorresponding quota tree and inode identifiers used to index the inodestructures that store the metadata. For example, as depicted in FIG. 3,the inode structures (or metadata itself) referenced by quota tree 1 (or“QTREE 1”) are indexed by inode identifiers 0, 2, 3, and 4, and theseinode identifiers are also stored in an inode grouped data structureassigned to quota tree 1. Similarly, the inode structures referenced byquota tree 0 (or “QTREE 0”) are indexed by inode identifiers 0, 1, and6, and these inode identifiers are stored in an inode grouped datastructure assigned to quota tree 0.

In accordance with exemplary embodiments of the present invention, theinode grouped data structures are allocated from the free blocks or fromthe quota tree metafile 302. In particular, the inode grouped datastructures are allocated based on available root directory inodeidentifiers and quota tree identifiers in the quota tree metafile 302,with a single inode grouped data structure allocated for each quotatree. For example, as depicted in FIG. 3, an inode grouped datastructure is allocated to quota tree identifier 0 with root directoryinode identifier 0. Another inode grouped data structure is allocated toquota tree identifier 1 with root directory inode identifier 1. The“LOCATION OF INODE GROUPED DATA STRUCTURE” column of the quota treemetafile 302 stores references to locations of the inode grouped datastructures in the file system. An example of such a reference can be ablock number to a particular inode grouped data structure. Anotherexample of such a reference can be an inode identifier of the datacontainer having inode grouped data structure.

From the quota tree metafile 302 and the inode grouped data structures,the quota trees, such as quota tree 0 and quota tree 1, can beconstructed. For example, the quota tree metafile 302 defines a quotatree identifier 0 assigned to a particular quota tree 0, and it has aroot directory identified or indexed by inode identifier 0. From readingthe inode grouped data structure associated with quota tree 0, thisquota tree 0 has inode identifiers 0, 1, and 6, and each inodeidentifier 0, 1, or 6 can be used to identify a unique quota tree,namely quota tree 0, 1, or 2. Furthermore, the quota tree identifiersassociated with inode identifiers 0, 1, and 6 can be used as an indexinto the root directory inode identifiers 0, 1, and 6. As an example,the quota tree identifier 2, which is associated with root directoryinode identifier 6, references a location of the inode grouped datastructure associated with quota tree 2. The inode grouped data structureassociated with quota tree 1 includes inode identifiers 0, 2, 3, and 4,which are used as an index to locate metadata associated with quota tree1.

By allocating an inode grouped data structure for each quota tree, aquota tree can be copied with its inode identifiers intact. That is, aquota tree can be copied without modifying or renumbering its inodeidentifiers. In the example depicted in FIG. 3, quota tree 2 is a copyof quota tree 1, which has inode identifiers 0, 2, 3, and 4. Given thatthe inode grouped data structures can store any inode identifiers, theinode identifiers stored in the inode grouped data structures allocatedto quota tree 1 and quota tree 2 can be identical (e.g., both storinginode identifiers 0, 2, 3, and 4). At the same time, the existingconstraints that the values of the quota tree identifiers and the rootdirectory inode identifiers are unique, which are imposed by the quotatree metafile 302, can be preserved.

FIG. 4 is a diagram depicting a copy of a quota tree in a differentvolume, in accordance with an exemplary embodiment of the presentinvention. In addition to making a copy of a quota tree within a singlevolume, a copy of the quota tree can also be made on a different volume.For example, as depicted in FIG. 4 and previously described in FIG. 3,quota tree 2 is a copy of quota tree 1, which is in volume 1.Additionally, quota tree 1 can also be copied to a different volume 2.When a file system for volume 2 is created, a quota tree metafile 402for volume 2 is also created. Similar to the quota tree metafile 302associated with volume 1, quota tree metafile 402 also stores variousinformation regarding all quota trees in volume 2, such as quota treeidentifiers, root directory inode identifiers, and references tolocations of inode grouped data structures.

Here, the quota tree 2 that is stored in volume 1, which is a copy ofquota tree 1, can be copied to volume 2 as quota tree 3 whilemaintaining the inode identifiers 0, 2, 3, and 4 originally allocated toquota trees 1 and 2. This quota tree 3 is therefore a tertiary copy ofquota tree 1. To make a copy of quota tree 2 in volume 2, an inodegrouped data structure is allocated for quota tree 3 from the quota treemetafile 402. Given that quota tree 3 is a copy of quota trees 1 and 2,the inode grouped data structure associated with quota tree 3 includes aset of inode identifiers 0, 2, 3, and 4 that are identical to the inodeidentifiers assigned to quota trees 1 and 2.

In reference to quota tree metafile 402, quota tree 0, which isidentified by quota tree identifier 0, is associated with root directoryinode identifier 0. The quota tree metafile 402 references an inodegrouped data structure for quota tree 0 that includes inode identifiers0 and 3. In turn, quota tree identifier 3, which is associated with rootdirectory inode identifier 3, can be used as an index into quota treemetafile 402 to identify a reference to a location of an inode groupeddata structure associated with quota tree 3. This inode grouped datastructure associated with quota tree 3 includes the set of inodeidentifiers 0, 2, 3, and 4.

FIG. 5 is a flow diagram of a general overview of a method 500, inaccordance with an exemplary embodiment, for creating a quota tree in afile system. In an exemplary embodiment, the method 500 may beimplemented by the quota tree replication module 202 and employed in thestorage server 152 depicted in FIG. 2. In reference to FIG. 5, uponcreation of a file system, a quota tree metafile is also created at 502to store various information about quota trees in a particular volume.As discussed above, in one embodiment, the quota tree metafile storesinformation such as quota tree identifiers, root directory inodeidentifiers, and references to locations of inode grouped datastructures.

Additionally, an inode grouped data structure is created for a rootdirectory at 504 where, as discussed previously, the inode grouped datastructure includes a set of inode identifiers as an index to locate theinode data structure or effectively, the metadata. The following Table Bis an example of a directory in a file system:

TABLE B Name of Data Container Inode identifier f1 0 f2 2As depicted in Table B, the directory includes two data containers,namely “f1” and “f2.” The data containers are stored in the followinginode grouped data structures depicted in Table C:

TABLE C Inode identifier Inode Data Structure 0 Details of f1: TypePermission Storage Quota User Identifier and Group Identifier 1 Unused 2Details of f2: Type Permission Storage Quota User Identifier and GroupIdentifierThe inode grouped data structure is at a known location in the filesystem (e.g., non-volatile memory, hard disk, or other storage devices).As depicted in Table C, the metadata are stored in the inode datastructures at locations 0 and 2.

Still referring to FIG. 5, a root directory inode identifier and a quotatree identifier are assigned to the root directory at 506 and 508,respectively. The newly assigned root directory inode identifier, quotatree identifier, and a reference to a location of the newly createdinode grouped data structure are then added as an entry in the quotatree metafile at 510.

FIG. 6 is a flow diagram of a general overview of a method 600, inaccordance with an exemplary embodiment, for creating a new quota treeor copying an existing quota tree. In an exemplary embodiment, themethod 600 may be implemented by the quota tree replication module 202and employed in the storage server 152 depicted in FIG. 2. In the method600 depicted in FIG. 6, a file system and a quota tree metafile havealready been created. Additionally, a quota tree has already beencreated for a root directory having a set of inode identifiers that arestored in its inode grouped data structure. A root directory inodeidentifier from this set of inode identifiers is allocated to a newquota tree at 602.

Furthermore, a unique quota tree identifier is assigned to the new quotatree at 604. It should be noted that each root directory inodeidentifier corresponds to a quota tree identifier. This quota treeidentifier serves as an index into the quota tree metafile. The rootdirectory of the quota tree is initialized with the new quota treeidentifier allocated during the creation of the quota tree.Subsequently, the data containers and/or directory inherit the quotatree identifier from the parent.

Still referring to FIG. 6, a new inode grouped data structure is createdfor the new quota tree at 606. In one embodiment, if the new quota treeis not a copy of another existing quota tree, then the new inode groupeddata structure can store any inode identifiers that can be used to indexinode data structures. In an alternate embodiment, if the new quota treeis a copy of an existing quota tree, then the new inode grouped datastructure stores a set of inode identifiers that are identical to theset of inode identifiers associated with the existing quota tree. Thatis, multiple sets of inode identifiers defined between at least twoinode grouped data structures can be identical. A reference to alocation of the new inode grouped data structure, the new quota treeidentifier, and the root directory inode identifier are then added as anentry in the quota tree metafile at 608.

FIG. 7 is a flow diagram of a general overview of a method 700, inaccordance with an exemplary embodiment of the present invention, foraccessing a quota tree to identify metadata. In an exemplary embodiment,the method 700 may be implemented by the quota tree replication module202 and employed in the storage server 152 depicted in FIG. 2. In method700, a quota tree metafile that includes references to locations ofinode grouped data structures is accessed at 702. As discussedpreviously, each quota tree has or is allocated an inode grouped datastructure, and a reference to a location of each inode grouped datastructure is stored in the quota tree metafile. In addition to thereferences, the quota tree metafile additionally stores quota treeidentifiers and root directory inode identifiers.

From the quota tree metafile, a reference to a location of an inodegrouped data structure that is associated with a particular quota treeis identified at 704, and the inode grouped data structure is thenaccessed at 706 based on this reference. This accessed inode groupeddata structure is stored in a file system and includes a set of inodeidentifiers that are associated with the quota tree. At 708, metadata(e.g., storage quota) can be located using the set of inode identifiersas index.

FIG. 8 is a flow diagram of a detailed method 800, in accordance with anexemplary embodiment of the present invention, for accessing a quotatree to identify metadata. In this detailed method 800, a directory pathidentifier is initially accessed, and this directory path identifierincludes at least one root directory. As depicted at 802, the inodeidentifier to start the search of directory path is identified (eithercurrent working directory of the process or root of the file system).Thereafter, a quota tree identifier associated with the inode identifieris identified from the quota tree metafile at 804. Using the quota treeidentifier as index into the quota tree metafile, a reference to alocation of the corresponding inode grouped data structure is identifiedand, at 806, the corresponding inode grouped data structure is accessedfrom that location.

This inode grouped data structure includes a set of inode identifiersassociated with the quota tree. The inode data structure associated witha current inode identifier is then read at 808 from the inode groupeddata structure. This inode identifier might correspond to the rootdirectory inode identifier in the quota tree metafile. The directoryentry is then read, and the inode identifier of the next component inthe directory entry is identified at 810. The inode data structure ofthis next component is then located at 812 in the inode grouped datastructure using the inode identifier as index.

Still referring to FIG. 8, a check is then made at 814 to determinewhether the end of the directory path has been reached or whether thereferenced data container does not exist. If the directory path hasreached the end or the data container does not exist, then the method800 ends. Metadata can be located by referencing the set of inodeidentifiers stored in the inode grouped data structure accessed at 806.However, if the directory path has not reached the end, then operationsat 804, 806, 808, 810, and 812 are repeated.

FIG. 9 is a data block diagram of a file system that supports quotatrees, in accordance with an exemplary embodiment of the presentinvention. As depicted, the file system 900 includes various data blocksassociated with inode identifiers 15 and 16. A super block 950 storesvarious information about the file system, such as a size of the filesystem and location of metadata on the disk. Inode identifiers 15 and 16are allocated from inode grouped data structures and reference metadata.Data blocks of inode identifier 15 store metadata, where data blocks ofinode identifier 16 store details of quota trees in the file system. Thequota tree metafile 902 stores quota tree identifiers, root directoryinode identifiers, and references to locations of inode grouped datastructures. Each inode grouped data structure stores a set of inodeidentifiers that are associated with a particular quota tree, such asquota tree 0, 1, or 2.

In the example depicted in FIG. 9, in order to identify metadataassociated with directory path “/dir1/f2,” the detailed method 800described in FIG. 8 for accessing a quota tree can be followed. Thisdirectory path identifier “/dir1/f2” includes a root directory “/.” Fromthe quota tree metafile 902, a root directory inode identifier “2” isidentified to be associated with the root directory “/.” Thereafter, thequota tree identifier “0” associated with the root directory inodeidentifier “2” is identified from the quota tree metafile 902. Using thequota tree identifier “0” as index into the quota tree metafile 902, areference to a location of the corresponding inode grouped datastructure “Metafile 20,” which is embodied within an inode grouped table“Inode table,” is identified, and this corresponding inode grouped datastructure “Metafile 20” is accessed from that location.

This inode grouped data structure “Metafile 20” includes a set of inodeidentifiers 10, 30, and 31 allocated to directory paths “/dir1,”“/dir2,” and “/file1,” respectively. The inode identifier “10” assignedto root directory path “/dir1” is identified as a next component afterroot directory “/,” and the inode identifier “10” assigned to this nextcomponent “/dir1” is identified from the inode grouped data structure“Metafile 20.”

A check is then made to determine whether the end of the directory path“/dir1/f2” has been reached or whether the data container “f2” does notexist. In this example, the end of the directory path “/dir/f2” has notbeen reached because “/f2” still exists and therefore, the quota treeidentifier “1” associated with the root directory inode identifier “10”is identified from the quota tree metafile 902. As discussed previously,the root inode identifier “10” is identified from Metafile 20 as theinode identifier allocated to root directory path “/dir1.”

Using the quota tree identifier “1” as index into the quota treemetafile 902, a reference to a location of a corresponding inode groupeddata structure “Metafile 21,” which is embodied within an inode groupedtable “Mode table,” is identified, and this corresponding inode datastructure “Metafile 21” is accessed from that location. The inode datastructure “Metafile 21” includes a set of inode identifiers associatedwith the quota tree identified by quota tree identifier “1.” Asdepicted, the set of inode identifiers read from the inode grouped datastructure “Metafile 21” are 10 and 20, allocated to directory paths“/dir1/f1” and “/dir1/f2,” respectively. The inode identifier “20”assigned to directory path “/dir1/f2” is identified as a next directorycomponent after directory path “/dir1,” and inode identifier “20”assigned to this next component “/dir1/f2” is identified from the inodegrouped data structure “Metafile 21.”

Another check is then made to determine whether the end of the directorypath “/dir1/f2” has been reached, and in this example, the end of thedirectory path “/dir1/f2” has been reached. Therefore, the inodeidentifier “20” in quota tree 1 can be used as an index to locate themetadata for directory path “/dir1/f2.”

FIG. 10 is a diagram of a system 1000 depicting a “fan-in” copy of quotatrees, in accordance with an exemplary embodiment of the presentinvention. The system 1000 includes three or more volumes, namely volume1, 2, and 3. As a result of maintaining an inode grouped data structurefor each quota tree, the same inode identifiers can be repeated fordifferent quota trees. As a result, the “fan-in” copy of quota trees canbe supported. In a fan-in copy, quota trees stored in different volumescan be copied to a single volume. That is, a single volume can hostcopies of the multiple quota trees.

For example, as depicted in FIG. 10, quota tree 1 is stored in volume 1while quota tree 2 is stored in volume 2. In a “fan-in” copy, quotatrees 1 and 2 can be copied to a single volume 3. Here, all the quotatrees 1 and 2 stored on volumes 1, 2, and 3 can have identical inodeidentifiers. Specifically, the inode identifiers in quota tree 1 onvolume 3 will be identical to inode identifiers in quota tree 1 onvolume 1. Similarly, inode identifiers in quota tree 2 on volume 3 willbe identical to inode identifiers in quota tree 2 on volume 2. In oneexample, such a fan-in copy can be used for used for vaulting, wherequota trees 1 and 2 can be restored to their respective volumes 1 and 2from volume 3 in case the primary copies of the quota trees 1 and 2stored on volumes 1 and 2 fail.

FIG. 11 is a diagram of a different system 1100 depicting a “cascade”copy of quota trees, in accordance with an alternative embodiment of thepresent invention. The system 1100 includes three volumes, namely volume1, 2, and 3. Each volume 1, 2, or 3 stores a quota tree 1, 2, or 3,respectively. In a cascade copy, secondary copy of a primary quota treeis used to create a tertiary copy. For example, as depicted in FIG. 11,quota tree 2, which is a secondary copy of primary quota tree 1, can beused to create quota tree 3, which is a tertiary copy of primary quotatree 1. As a result of maintaining an inode grouped data structure foreach quota tree 1, 2, or 3, the same inode identifiers can be repeatedfor different quota trees 1, 2, and 3, thereby allowing cascade copiesof quota tree 1 to be made having the same set of inode identifiers. Asa result, upon restoring quota tree 1 from either quota tree 2 or 3 incase of a failover, there is no difference between the primary,secondary, and tertiary copies.

FIG. 12 depicts a hardware block diagram of a machine in the exampleform of a computing device 1200 within which may be executed a set ofinstructions for causing the machine to perform any one or more of themethodologies discussed herein. In alternative embodiments, the machineoperates as a standalone device or may be connected (e.g., networked) toother machines. In a networked deployment, the machine may operate inthe capacity of a server or as a peer machine in a peer-to-peer (ordistributed) network environment.

The machine is capable of executing a set of instructions (sequential orotherwise) that specify actions to be taken by that machine. Further,while only a single machine is illustrated, the term “machine” shallalso be taken to include any collection of machines that individually orjointly execute a set (or multiple sets) of instructions to perform anyone or more of the methodologies discussed herein.

The example of the computing device 1200 includes a processor 1202(e.g., a central processing unit (CPU), a graphics processing unit (GPU)or both), a main memory 1204 (e.g., random access memory), and a staticmemory 1206 (e.g., static random access memory), which communicate witheach other via bus 1208. The computing device 1200 may further includevideo display unit 1210 (e.g., a plasma display, a liquid crystaldisplay (LCD) or a cathode ray tube (CRT)). The computing device 1200also includes an alphanumeric input device 1212 (e.g., a keyboard), auser interface (UI) navigation device 1214 (e.g., a mouse), a disk driveunit 1216, a signal generation device 1218 (e.g., a speaker), and anetwork interface device 1220.

The disk drive unit 1216 (a type of non-volatile memory storage)includes a machine-readable medium 1222 on which is stored one or moresets of data structures and instructions 1224 (e.g., software) embodyingor utilized by any one or more of the methodologies or functionsdescribed herein. The data structures and instructions 1224 may alsoreside, completely or at least partially, within the main memory 1204and/or within the processor 1202 during execution thereof by computingdevice 1200, with the main memory 1204 and processor 1202 alsoconstituting machine-readable, tangible media.

The data structures and instructions 1224 may further be transmitted orreceived over a computer network 150 via network interface device 1220utilizing any one of a number of well-known transfer protocols (e.g.,HyperText Transfer Protocol (HTTP)).

Certain embodiments are described herein as including logic or a numberof components, modules, or mechanisms. Modules may constitute softwaremodules (e.g., code embodied on a machine-readable medium or in atransmission signal) and/or hardware modules. A hardware module is atangible unit capable of performing certain operations and may beconfigured or arranged in a certain manner. In exemplary embodiments,one or more computer systems (e.g., the computing device 1200) or one ormore hardware modules of a computer system (e.g., a processor 1202 or agroup of processors) may be configured by software (e.g., an applicationor application portion) as a hardware module that operates to performcertain operations as described herein.

In various embodiments, a hardware module may be implementedmechanically or electronically. For example, a hardware module maycomprise dedicated circuitry or logic that is permanently configured(e.g., as a special-purpose processor, such as a field programmable gatearray (FPGA) or an ASIC to perform certain operations. A hardware modulemay also comprise programmable logic or circuitry (e.g., as encompassedwithin a general-purpose processor 1202 or other programmable processor)that is temporarily configured by software to perform certainoperations. It will be appreciated that the decision to implement ahardware module mechanically, in dedicated and permanently configuredcircuitry, or in temporarily configured circuitry (e.g., configured bysoftware) may be driven by cost and time considerations.

Accordingly, the term “hardware module” should be understood toencompass a tangible entity, be that an entity that is physicallyconstructed, permanently configured (e.g., hardwired) or temporarilyconfigured (e.g., programmed) to operate in a certain manner and/or toperform certain operations described herein. Considering embodiments inwhich hardware modules are temporarily configured (e.g., programmed),each of the hardware modules need not be configured or instantiated atany one instance in time. For example, where the hardware modulescomprise a general-purpose processor 1202 configured using software, thegeneral-purpose processor 1202 may be configured as respective differenthardware modules at different times. Software may accordingly configurea processor 1202, for example, to constitute a particular hardwaremodule at one instance of time and to constitute a different hardwaremodule at a different instance of time.

Modules can provide information to, and receive information from, othermodules. For example, the described modules may be regarded as beingcommunicatively coupled. Where multiples of such hardware modules existcontemporaneously, communications may be achieved through signaltransmission (e.g., over appropriate circuits and buses) that connectthe modules. In embodiments in which multiple modules are configured orinstantiated at different times, communications between such modules maybe achieved, for example, through the storage and retrieval ofinformation in memory structures to which the multiple modules haveaccess. For example, one module may perform an operation, and store theoutput of that operation in a memory device to which it iscommunicatively coupled. A further module may then, at a later time,access the memory device to retrieve and process the stored output.Modules may also initiate communications with input or output devices,and can operate on a resource (e.g., a collection of information).

The various operations of example methods described herein may beperformed, at least partially, by one or more processors 1202 that aretemporarily configured (e.g., by software) or permanently configured toperform the relevant operations. Whether temporarily or permanentlyconfigured, such processors 1202 may constitute processor-implementedmodules that operate to perform one or more operations or functions. Themodules referred to herein may, in some exemplary embodiments, compriseprocessor-implemented modules.

Similarly, the methods described herein may be at least partiallyprocessor-implemented. For example, at least some of the operations of amethod may be performed by one or more processors 1202 orprocessor-implemented modules. The performance of certain of theoperations may be distributed among the one or more processors 1202, notonly residing within a single machine, but deployed across a number ofmachines. In some exemplary embodiments, the processors 1202 may belocated in a single location (e.g., within a home environment, an officeenvironment or as a server farm), while in other embodiments theprocessors 1202 may be distributed across a number of locations.

While the embodiment(s) is (are) described with reference to variousimplementations and exploitations, it will be understood that theseembodiments are illustrative and that the scope of the embodiment(s) isnot limited to them. In general, techniques for the creation and accessof quota trees in a file system may be implemented with facilitiesconsistent with any hardware system or hardware systems defined herein.Many variations, modifications, additions, and improvements arepossible.

Plural instances may be provided for components, operations orstructures described herein as a single instance. Finally, boundariesbetween various components, operations, and data stores are somewhatarbitrary, and particular operations are illustrated in the context ofspecific illustrative configurations. Other allocations of functionalityare envisioned and may fall within the scope of the embodiment(s). Ingeneral, structures and functionality presented as separate componentsin the exemplary configurations may be implemented as a combinedstructure or component. Similarly, structures and functionalitypresented as a single component may be implemented as separatecomponents. These and other variations, modifications, additions, andimprovements fall within the scope of the embodiment(s).

What is claimed is:
 1. A method of identifying metadata referenced by atarget quota tree, the method comprising: accessing a quota treemetafile that includes a reference to a location of an inode groupeddata structure for each of a plurality of quota trees in a file system,wherein each of the inode grouped data structures stores (i) a set ofinode identifiers that includes an inode identifier for each datacontainer associated with the inode grouped data structure'scorresponding quota tree, and (ii) a separately indexed metadata entryfor each of the inode identifiers in the set; identifying, from thequota tree metafile, the reference to the location of the inode groupeddata structure for the target quota tree, wherein the target quota treeis one of the plurality of quota trees in the file system; accessing theinode grouped data structure based on the reference; and locating themetadata referenced by the target quota tree using at least one of theinode identifiers from the set of inode identifiers as an index for theseparately indexed metadata entries.
 2. The method of claim 1, furthercomprising: accessing a directory path identifier that includes a rootdirectory; identifying, from the inode grouped data structure, a rootdirectory inode identifier associated with the root directory;identifying, from the quota tree metafile, a quota tree identifierassociated with the root directory inode identifier; identifying, fromthe quota tree metafile, an additional reference to a location of anadditional inode grouped data structure using the quota tree identifieras the index; and accessing the additional inode grouped data structurebased on the additional reference, the additional inode grouped datastructure defining an additional set of inode identifiers associatedwith an additional quota tree, wherein the metadata is located using theadditional set of inode identifiers as the index.
 3. The method of claim1, wherein the quota tree metafile additionally includes quota treeidentifiers and root directory inode identifiers that are associatedwith the references to the locations of the inode grouped datastructures; and wherein the root directory inode identifiers are unique.4. The method of claim 1, wherein a number of the sets of inodeidentifiers defined between at least two inode grouped data structuresare identical.
 5. The method of claim 1, wherein the quota tree metafilestores information regarding all quota trees in a single volume of astorage device, and wherein each volume of the storage device contains asingle quota tree metafile.
 6. A method of creating a quota tree in afile system, the method comprising: creating a quota tree metafile;creating an inode grouped data structure for a root directory, the inodegrouped data structure including (i) a set of inode identifiers thatincludes an inode identifier for each data container associated with theinode grouped data structure's corresponding quota tree, and (ii) aseparately indexed metadata entry for each of the inode identifiers inthe set; assigning a root directory inode identifier to the rootdirectory; assigning a quota tree identifier to the root directory; andadding a reference to a location of the inode grouped data structure,the root directory inode identifier, and the quota tree identifier tothe quota tree metafile.
 7. The method of claim 6, wherein an inodeidentifier in the set of inode identifiers identifies a unique quotatree.
 8. The method of claim 6, further comprising: allocating a secondroot directory inode identifier from the set of inode identifiers to asecond quota tree; assigning a second quota tree identifier to thesecond quota tree; creating a second inode grouped data structure forthe second quota tree, the second inode grouped data structure includinga second set of inode identifiers; and adding a reference to a locationof the second inode grouped data structure, the second root directoryinode identifier, and the second quota tree identifier to the quota treemetafile.
 9. The method of claim 8, wherein the root directory inodeidentifier and the second root directory inode identifier are unique.10. The method of claim 8, wherein the quota tree identifier and thesecond quota tree identifier are unique.
 11. The method of claim 8,further comprising: allocating a third root directory inode identifierfrom the set of inode identifiers to a third quota tree that is a copyof the second quota tree; assigning a third quota tree identifier to thethird quota tree; creating a third inode grouped data structure for thethird quota tree, the third inode grouped data structure including athird set of inode identifiers that is identical to the second set ofinode identifiers; and adding a reference to a location of the thirdinode grouped data structure, the third root directory inode identifier,and the third quota tree identifier to the quota tree metafile.
 12. Themethod of claim 11, wherein the second quota tree is stored in a firstvolume and the third quota tree is stored in a second volume.
 13. Themethod of claim 6, further comprising: copying the quota tree from afirst volume to a second volume; creating a secondary inode grouped datastructure for a secondary quota tree on the second volume which containsan identical set of inode identifiers as the inode grouped datastructure for the quota tree on the first volume; copying the secondaryquota tree on the second volume to a third volume; creating a tertiarynew inode grouped data structure for a tertiary quota tree on the thirdvolume which contains an identical set of inode identifiers as the inodegrouped data structures for the quota trees on the first and secondvolumes; and using the tertiary quota tree as part of a process torestore data on the first volume.
 14. A non-transitory, machine-readablemedium that stores instructions, which, when performed by a machine,cause the machine to perform operations comprising: accessing a quotatree metafile that includes a reference to a location of an inodegrouped data structure for each of a plurality of quota trees in a filesystem, wherein each of the inode grouped data structures stores (i) aset of inode identifiers that includes an inode identifier for each datacontainer associated with the inode grouped data structure'scorresponding quota tree, and (ii) a separately indexed metadata entryfor each of the inode identifiers in the set; identifying, from thequota tree metafile, the reference to the location of the inode groupeddata structure for a target quota tree, wherein the target quota tree isone of the plurality of quota trees in the file system; accessing theinode grouped data structure based on the reference; and locatingmetadata referenced by the target quota tree using at least one of theinode identifiers from the set of inode identifiers as an index for theseparately indexed metadata entries.
 15. The non-transitory,machine-readable medium of claim 14, further comprising instructionsthat cause the machine to perform operations including: accessing adirectory path identifier that includes a root directory; identifying,from the inode grouped data structure, a root directory inode identifierassociated with the root directory; identifying, from the quota treemetafile, a quota tree identifier associated with the root directoryinode identifier; identifying, from the quota tree metafile, anadditional reference to a location of an additional inode grouped datastructure using the quota tree identifier as the index; and accessingthe additional inode grouped data structure based on the additionalreference, the additional inode grouped data structure defining anadditional set of inode identifiers associated with an additional quotatree, wherein the metadata is located using the additional set of inodeidentifiers as the index.
 16. The non-transitory, machine-readablemedium of claim 14, wherein the quota tree metafile additionallyincludes quota tree identifiers and root directory inode identifiersthat are associated with the references to the locations of the inodegrouped data structures; and wherein the root directory inodeidentifiers are unique.
 17. The non-transitory, machine-readable mediumof claim 14, wherein the inode grouped data structures include sets ofinode identifiers; and wherein a number of the sets of inode identifiersdefined between at least two inode grouped data structures areidentical.
 18. The non-transitory, machine-readable medium of claim 14,wherein the quota tree metafile stores information regarding all quotatrees in a single volume of a storage device, and wherein each volume ofthe storage device contains a single quota tree metafile.
 19. Acomputing device comprising: a processor; and a memory in communicationwith the processor, the memory being configured to store a quota treereplication module that is executable by the processor, the quota treereplication module having instructions that when executed by theprocessor, cause operations to be performed, the operations comprising:creating a quota tree metafile; creating an inode grouped data structurefor a root directory, the inode grouped data structure including (i) aset of inode identifiers that includes an inode identifier for each datacontainer associated with the inode grouped data structure'scorresponding quota tree, and (ii) a separately indexed metadata entryfor each of the inode identifiers in the set; assigning a root directoryinode identifier to the root directory; assigning a quota treeidentifier to the root directory; and adding a reference to a locationof the inode grouped data structure, the root directory inodeidentifier, and the quota tree identifier to the quota tree metafile.20. The computing device of claim 19, wherein the operations furthercomprise: allocating a second root directory inode identifier from theset of inode identifiers to a second quota tree; assigning a secondquota tree identifier to the second quota tree; creating a second inodegrouped data structure for the second quota tree, the second inodegrouped data structure including a second set of inode identifiers; andadding a reference to a location of the second inode grouped datastructure, the second root directory inode identifier, and the secondquota tree identifier to the quota tree metafile.
 21. The computingdevice of claim 19, wherein the operations further comprise: copying aquota tree from a first volume to a second volume; creating a secondaryinode grouped data structure for a secondary quota tree on the secondvolume which contains an identical set of inode identifiers as the inodegrouped data structure for the quota tree on the first volume; copyingthe secondary quota tree on the second volume to a third volume;creating a tertiary new inode grouped data structure for a tertiaryquota tree on the third volume which contains an identical set of inodeidentifiers as the inode grouped data structures for the quota trees onthe first and second volumes; and using the tertiary quota tree as partof a process to restore data on the first volume.